home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4231 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.4 KB  |  73 lines
  1. Path: news.daimi.aau.dk!liborius
  2. From: liborius@daimi.aau.dk (Per Liboriussen)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: 3 bugs in SAS/C v. 6.56
  5. Date: 26 Feb 1996 10:54:44 GMT
  6. Organization: DAIMI, Computer Science Dept. at Aarhus University
  7. Message-ID: <4gs3hk$7mp@gjallar.daimi.aau.dk>
  8. References: <4gjvvc$a3t@gjallar.daimi.aau.dk> <312EFB06.708D@diku.dk>
  9. NNTP-Posting-Host: drachma.daimi.aau.dk
  10.  
  11. Thus spake Morten B=?iso-8859-2?Q?=F8geskov Jensen <bogeskov@diku.dk>?=:
  12.  
  13. >#include <stdio.h>
  14.  
  15. >int main(void)
  16. >{
  17. >    unsigned short a = 0xffff, b = 0xffff;
  18.  
  19. >    if ((a | b) > (unsigned short)0x7fff) {
  20. >        printf("ok\n");
  21. >    } else {
  22. >        printf("bad\n");
  23. >    }
  24. >    return 0;
  25. >}
  26.  
  27. >This should work.. But I haven't tested it, since I'm not at home, so I
  28. >cannot reach out and get SAS/C.
  29.  
  30. Neither am I, so the same goes for me. However, a working workaround is
  31. something like:
  32.   ...
  33.   unsigned short x = (a | b);
  34.  
  35.   if (x > 0x7fff) {
  36.   ...
  37.  
  38. The problem is not finding the workaround, it is finding the code that causes
  39. the problems.
  40.  
  41. >However I belive that ">" and other boolean operations are
  42. >left-associative (I know), as so they take the type of the 2nd (right)
  43. >parameter, and since 0x7fff per default is signed, there is an implicit
  44. >type conversion of unsigned short to signed short. this is most
  45. >unfortunate, however this is the way most C-compilers work.
  46.  
  47. I don't see what the associativeness of ">" has to do with the above.
  48. Anyway, when a compiler evaluates a boolean expression such as ">", it
  49. must perform the usual integral promotions. This means that types narrower
  50. than int are promoted to int before the comparison. Even in your example
  51. above the compiler must take the (integer) constant 0x7fff, convert it to
  52. unsigned short, and then immediately convert it back to int. Of course,
  53. the ISO C Standard does give permission for an implementation to carry out
  54. the comparison by any arcane magic it may wish, as long as a conforming
  55. program is not able to tell the difference. (The "as if" rule.)
  56.  
  57. (Note furthermore that even though a and b are both unsigned shorts, the
  58. type of the expression (a | b) is int!)
  59.  
  60. Since an int in this case is capable of representing all possible values
  61. of an unsigned short, the promotion of a and b to int must be
  62. value-preserving.
  63.  
  64.  
  65. >The other 2 examples I couldnt see why they wouldn't work.
  66.  
  67. As the subject line says: Bugs. ;-)
  68.  
  69.  
  70. --
  71. Per Liboriussen
  72. liborius@daimi.aau.dk
  73.